Lecture 7 — Unit III opens: how organisations actually move to DevOps, the manufacturing philosophy it borrows from, and why adoption is harder than installing a pipeline.
"You can buy a CI server in an afternoon. You cannot buy a culture that trusts a green pipeline over a manual sign-off." — the adoption problem, in one line
Practices, tools, and the theoretical case for DevOps.
How an organisation actually changes its habits to get there.
Most failed DevOps initiatives fail on people and process, not technology.
DevOps adoption is the organisational journey of shifting how people, process, and technology work together — moving from siloed, hand-off-driven delivery to a shared, automated, feedback-driven flow from idea to production.
Shared ownership, blameless learning, breaking the Dev-vs-Ops mentality.
Smaller batches, faster feedback loops, work made visible end-to-end.
CI/CD, IaC and monitoring — but only as the enabler, never the goal itself.
DevOps is never "turned on" in one release. Most organisations move through recognisable stages — each one building trust before the next is attempted.
One team automates its own builds and tests. Proves the idea on a small, low-risk surface.
Pipelines connect Dev → QA → Ops. Shared dashboards replace status-update meetings.
DevOps becomes "how we work" — self-service infra, continuous deployment, shared on-call.
Lean thinking originates in 1950s Toyota manufacturing: the goal was to deliver exactly what the customer needs, in the right amount, at the right time — with the least possible waste.
DevOps borrows this thinking wholesale: a deployment pipeline is a production line for software.
Code sitting in branches, unmerged, untested.
Redundant approvals, change boards, duplicate sign-offs.
Gold-plating — building what nobody asked for.
Engineers split across too many projects at once.
For environments, approvals, test results, releases.
Work passed Dev → QA → Ops with context lost each time.
Bugs found late, costing far more to fix than early.
Spotting these in your own delivery process is the first concrete Lean skill — and the starting point for any Kaizen improvement.
Chart every step from commit to production, and mark where work waits versus where it's actually worked on.
Smaller, more frequent releases reduce risk and surface problems while they're still cheap to fix.
Teams pull the next item when they have capacity — mirrored directly by Kanban boards and WIP limits.
Kaizen means continuous, incremental improvement — made by the people doing the work, every day, rather than occasional big-bang transformation projects.
It assumes no process is ever finished; it can always get a little better tomorrow.
DevOps relies heavily on Process Kaizen: engineers closest to the pipeline fix friction first.
Short, regular reflection on what slowed the team down — and one small fix to try next.
Failures are treated as data about the system, not as someone's mistake to punish.
Anyone can halt a broken build — the same principle as a factory worker pulling the andon cord.
Notice the pattern: Lean gives DevOps its map (where the waste is), Kaizen gives it its habit (always closing the gap).
Shared ownership over hand-offs and blame.
Removing manual, repeatable toil from the pipeline.
Small batches, visible flow, waste eliminated.
Lead time, deployment frequency, change failure rate.
Knowledge and incidents shared openly across teams.
Lean & Kaizen sit at the core of two of these five letters.
Teams comfortable with existing roles resist shared ownership and accountability.
Dev, QA and Ops report to different leaders with different, sometimes conflicting, incentives.
Adopting tools without aligning process first creates automation around a broken workflow.
Engineers need new scripting, cloud and automation skills that take real time to build.
Monolithic, tightly coupled applications resist fast, independent, frequent releases.
Without the right metrics, leadership can't tell real progress from busywork.
Recall the silo case study from Lecture 6. Now reframe it through today's lens: which of the 7 wastes were visible in that scenario? Was the fix mainly cultural, process-based, or technical — and which Kaizen habit would have caught the problem earliest?
Monolithic vs Microservices architecture; Cloud & DevOps resiliency.
Think of one waste from today's list that you've personally experienced in a group project or internship.